В прошлом году я обещал выложить оффлайн-демо продуктов VMware, которые не попали в обзор, в случае, если будет запрос на их выкладывание сюда. Запросов оказалось достаточно, поэтому продолжим эту традицию, но уже без обзора, а просто выложим файлы списком.
Отличный пост про симулятор сервера vCenter написал William Lam. Изложим здесь его вкратце. Когда-то два человека, Zhelong Pan и Kinshuk Govil, написали утилиту vcsim, которая позволяет эмулировать сервер VMware vCenter в котором запущены тысячи виртуальных машин, при этом такие объекты потребляют минимум ресурсов и работают на минимальной конфигурации VMware vCSA (vCenter Server Appliance). Утилита входит в состав vCSA, но отсутствует в обычной инсталляции vCenter.
Помимо собственно построения виртуального Inventory сервера vCenter из виртуальных машин и хост-серверов, утилита vcsim поддерживает простейшие операции с фейковыми объектами, например, Power On ненастоящих машин, а также различные метрики производительности. Кроме того, с помощью этой утилиты можно и добавлять настоящие серверы VMware ESXi и виртуальные машины, создавая гибридную конфигурацию, так как vcsim - это, все же, настоящий vCenter Server.
Теперь приведем ситуации, когда такая конфигурация может оказаться полезной:
При изучении vSphere API для исследования функций навигации по иерархии.
Возможность создать "виртуальное" окружение для тестирования различных скриптов.
Разработка утилит, отслеживающих производительность
Разработка плагинов к vSphere Web Client
Для начала работы с vcsim нужно внести изменения в файл /etc/vmware-vpx/vpxd.cfg, поместив туда следующее между тэгами </vpxd> и </config>:
Кстати, шаблон конфигурации vcsim представлен в файле:
/etc/vmware-vpx/vcsim/model/vcsim.cfg.template
После этого нужно перезапустить сервис vCenter:
service vmware-vpxd restart
Такой перзапуск сервиса можно делать только один раз (даже если он был не успешен), дальше будут использоваться другие команды, приведенные ниже.
После рестарта сервиса мы можем увидеть окружение с сотнями хост-серверов и десятью тысячами виртуальных машин, как в веб-клиенте:
\
так и в "толстом" клиенте:
Теперь мы можем менять параметры окружения в файле:
/etc/vmware-vpx/vcsim/model/initInventory.cfg
В нем можно настраивать следующие объекты:
Datacenter
Hosts per Datacenter
VM per Host
Powered On VM per Host
Cluster per Datacenter
Host Per Cluster
Resource Pool per Cluster
VM per Resource Pool
Powered On VM
vCPU for a VM
vMEM for a VM
После того, как вы сохранили внесенные в конфигурацию изменения, нужно выполнить команду vpxd -b, чтобы пересоздать базу симулируемого vCenter. Поэтому выполняем следующую последовательность для рестарта сервиса:
service vmware-vpxd stop vpxd -b
service vmware-vpxd start
Кроме того, vcsim использует следующие конфигурационные файлы:
vcsim/model/metricMetadata.cfg (симулируемые Performance Metrics - по умолчанию их нет)
vcsim/model/vcModules.cfg (симулируемые модули vCenter, например, DRS)
vcsim/model/OperationDelay.cfg (задержки выполнения операций)
Так что теперь можно испытывать эту штуку и экспериментировать в свободное время. Ну и, само собой, все это никак не поддерживается со стороны VMware.
Таги: VMware, vCenter, vcsim, Blogs, ESXi, VMachines, Обучение
Так как приближаются праздники, мы хотим от всей души поздравить читателей VM Guru с Новым годом, поблагодарить их за сотрудничество в прошедшем году и надеемся на успешное его продолжение в 2013-м. Нам очень понравилось работа с нашими пользователями в уходящем году, и мы надеемся что для всех вас Новый год будет заполнен радостью, счастьем и успехом.
Примите наши искренние поздравления с наступающим Новым годом от всей дружной команды StarWind!
В конце декабря модно давать прогнозы, касающиеся развития технологий в следующем году. Сфера облачных вычислений и технологий виртуализации - не исключение. В этом посте мы постарались собрать наиболее значимые прогнозы, которые в последнее время появились на страницах различных изданий и блогов.
Итак:
Прогноз от Savvis - в 2013 году облака будут все еще on-premise, т.е. работать в пределах инфраструктуры компании. Выиграют те сервис-провайдеры, которые смогут предоставлять гибридную модель онпремизно-офпремизных услуг. Об этом же говорит и прогноз BlueStripe - крупные компании, само собой, от частного облака в публичное никогда полностью не уйдут - критичные сервисы всегда будут в своем датацентре:
Прогноз от Veeam Software - гипервизоры VMware и Microsoft будут сосуществовать в инфраструктурах компаний, а также средний и малый бизнес будет использовать возможности виртуализции, которые традиционно считались доступными только Enteprise-сектору.
В том же прогнозе рассказано про HPC Cloud Computig - высокопроизводительные публичные облака. На эту тему, конечно же, мы вспомним нашу заметку "Еще одно публичное облако IaaS - Google Compute Engine". И дествительно, кому как не Гуглу таким заниматься? Но надо помнить, что на этом рынке есть еще Microsoft (вот тут) и, конечно же, первопроходец облачных сервисов - Amazon (вот тут).
Прогноз от Citrix - концепция BYOD будет мейнстримом. Такой прогноз от Citrix неудивителен, поскольку компания предоставляет средства создания инфраструктуры доступа к корпоративным приложениям с любого устройства, которое захотел пользователь. Интересно также мнение Citrix о том, что Windows-приложения уже не будут рулить как раньше - это очевидно, поскольку все мы знаем, кто захватил мобильные платформы.
Также еще несколько предсказаний вы можете почитать вот тут. Ну и интереснейшая серия прогнозов на 2013 год вот тут (я выбрал самые интересные):
Продолжаем вас знакомить с продуктом номер 1 - vGate R2, предназначенным для защиты виртуальных сред VMware vSphere. Напомним, что он позволяет производить автоматическую настройку конфигурации безопасности хост-серверов VMware ESX / ESXi средствами политик, защищать инфраструктуру от несанционированного доступа, а также имеет все необходимые сертификаты ФСТЭК. В этой статье мы приведем все актуальные на сегодняшний день возможности vGate R2...
Некоторые партнеры VMware знают, что у компании есть оффлайновые демки продуктов, которые прекрасно подходят для того, чтобы знакомиться с теми продуктами, которые не хочется полноценно развертывать в своей ИТ-инфраструктуре. Эти демки, которые можно кликать, проводят по шагам настройки основных параметров продуктов и показывают их "внутренности". Штуки эти очень полезные для понимания функциональности решений, поэтому мы решили выложить некоторые из них тут, чтобы донести их в массы.
Первое - это то, с чем должен быть знаком каждый администратор VMware vSphere - решение vCloud Director 5.1, которое является базой для создания частных и гибридных облаков на основе продуктов VMware.
Второе - это распределенный коммутатор Cisco Nexus Distributed Switch. Многие компании применяют распределенный коммутатор от VMware (vDS) и мало знакомы с решением от Cisco, которое предоставляет намного больше возможностей.
Третье - это компонент VMware vCenter Orchestrator, который представляет собой средство автоматизации операций в виртуальной инфраструктуре. Если у вас больше 3-5 хост-серверов VMware ESXi, вам обязательно нужно потыкать демку:
В данной части рассмотрим рекомендации к настройке виртуальных десктопов, как собственно виртуальных машин и их параметров, так и их гостевой операционной системы. Рекомендуется виртуальному десктопу назначать только одну сетевую карту (сетевой адаптер). Во-первых, в большинстве случаев пользователю просто не нужно две сетевые карты, а, во-вторых, сетевые карты естественно будут подключены к разным сетям и могут "шунтировать" межсетевой экран и маршрутизировать пакеты между этими сетями бесконтрольно... Таги: VMware, View, Security, Blogs, Enterprise, VDI
Для начала обратите внимание, что обновление вышло не для ESXi 5.1 (последней версии гипервизора), а для ESXi 5.0 - его предыдущей версии. Так что это обновление актуально только для тех, кто еще не успел переехать со старой версии платформы.
Помимо VMware ESXi 5.0 Update 2, вышел и VMware vCenter 5.0 Update 2. Новые возможности обновлений:
Официальная поддержка работы vCenter 5.0 на Windows Server 2012.
Официальная поддержка новых гостевых ОС: Oracle Solaris 11, Solaris 11.1, а также Mac OS X Server Lion 10.7.5.
Поддержка сервером vCenter механизма Guest Operating System Customization для следующих гостевых ОС: Windows 8, Windows Server 2012, Ubuntu 12.04, RHEL 6.2, RHEL 6.3.
Одновременно с этим компания StarWind объявила также о том, что решение StarWind iSCSI SAN 6.0 для хранения виртуальных машин VMware vSphere также становится бесплатным (при использовании дисковых ресурсов до 128 ГБ), при этом доступны все возможности продукта для обеспечения отказоустойчивости хранилищ. Об этом подробно написано в документе "StarWind iSCSI SAN Free. The difference between free and paid editions".
Для тех, кому лень открывать документ на английском, приводим обновленное сравнение бесплатного и коммерческого изданий StarWind iSCSI SAN 6.0:
StarWind iSCSI SAN
Free Edition - бесплатно
Коммерческие издания (в зависимости от лицензируемой емкости 1 ТБ - 512 ТБ)
Компоненты продукта
Лицензируемая емкость хранилищ
Не ограничена для одного узла и ограничение 128 ГБ для HA-конфигурации (на узел)
1 ТБ - 512 ТБ
Размер кэша
512 МБ
Не ограничен
Централизованное управление
StarWind Console
StarWind Console
Число серверов, входящее в лицензию
2
2 или 3
Число одновременных соединений по iSCSI к хранилищам
В городе Нижний Новгород 5 декабря пройдет Форум «ВОКРУГ ЦОД-2012». Форум ориентирован на руководителей предприятий и направлений, ИТ специалистов и администраторов, проектировщиков и инженеров, менеджеров проектов и представителей заказчика, отвечающих за инженерную и ИТ инфраструктуру, разработку технического задания и требований на проектирование серверных и центров обработки данных. Форум — это большая конференция и выставка. «Вокруг ЦОД» — это все, что связано с центрами обработки данных — решения, услуги, продукты, технологии и экспертиза. Таги:
Продолжаем знакомить вас с продуктом vGate R2 от компании Код Безопасности, который предназначен для защиты виртуальной инфраструктуры VMware vSphere средствами политик безопасности для хост-серверов и виртуальных машин, а также средствами защиты от несанкционированного доступа (НСД). Недавно мы писали о совместном использовании продукта vGate R2 со средством Secred Net для создания комплексной инфраструктуры защиты от НСД.
Совсем недавно компания "Код Безопасности" анонсировала новую версию своего флагманского решения, которая получила название Secret Net 7. Решение дает заказчикам новый уровень защищенности и удобства эксплуатации системы защиты.
Во-первых, добавился новый вариант внедрения – это более удобная схема установки сетевой версии Secret Net в организациях с филиальной структурой. В новой версии реализована поддержка ADAM/LDS, при этом решается проблема делегирования полномочий администраторам на установку и эксплуатацию СЗИ в рамках организационного подразделения или филиала. Важным изменением является возможность защиты терминальных сессий с использованием технологии "тонкий клиент" ввиду все более широкого ее распространения. Поддержка терминального режима доступа для платформ Citrix и Microsoft. Помимо прочего, в Secret Net 7 расширены возможности по контролю утечек конфиденциальной информации – теперь СЗИ обеспечивает возможность теневого копирования до операции записи информации на устройство. Кроме того, стал доступен универсальный контроль печати, позволяющий выводить гриф конфиденциальности на документы, распечатываемые из любого приложения, а также реализовано разграничение доступа к принтерам – печать конфиденциальных документов только на специально выделенных для этих целей принтерах.
В Secret Net 7 реализованы новые возможности средства централизованного управления и мониторинга. В их числе...
Кроме того, не так давно были воплощены в жизнь такие полезные службы vSphere для работы с SSD-накопителями, как SSD Monitoring (реализуется демоном smartd) и Swap to SSD (использование локальных дисков для файлов подкачки виртуальных машин). Однако функции кэширования на SSD реализованы пока совсем в базовом варианте, поэтому сегодня вам будет интересно узнать о новой технологии Virtual Flash (vFlash) для SSD-накопителей в VMware vSphere, которая была анонсирована совсем недавно.
Эта технология, находящаяся в стадии Tech Preview, направлена на дальнейшую интеграцию SSD-накопителей и других flash-устройств в инфраструктуру хранения VMware vSphere. Прежде всего, vFlash - это средство, позволяющее объединить SSD-ресурсы хост-серверов VMware ESXi в единый пул, используемый для задач кэширования, чтобы повысить быстродействие виртуальных машин. vFlash - это фреймворк, позволяющий сторонним вендорам SSD-накопителей и кэш-устройств использовать собственные алгоритмы для создания модулей обработки кэшей виртуальных машин (плагины vFlash Cache Modules). Будет реализован и собственный базовый алгоритм VMware для работы с кэшем.
Основная мысль VMware - предоставить партнерам некий API для их flash-устройств, за счет которого виртуальные машины будут "умно" использовать алгоритмы кэширования. Для этого можно будет использовать 2 подхода к кэшированию: VM-aware caching и VM-transparent caching:
VM-aware Caching (vFlash Memory)
В этом режиме обработки кэширования флэш-ресурс доступен напрямую для виртуальной машины, которая может использовать его на уровне блоков. В этом случае на уровне виртуального аппаратного обеспечения у виртуальной машины есть ресурс vFlash Memory определенного объема, который она может использовать как обычный диск в гостевой ОС. То есть, приложение или операционная система должны сами думать, как этот высокопроизводительный ресурс использовать. Можно вообще использовать его не как кэш, а как обычный диск, хотя идея, конечно же, не в этом.
VM-transparent Caching (vFlash Cache)
В этом случае виртуальная машина и ее гостевая ОС не знают, что на пути команд ввода-вывода находится прослойка в виде flash-устройств, оптимизирующих производительность за счет кэширования. В этом случае задача специализированного ПО (в том числе от партнеров) - предоставить оптимальный алгоритм кэширования. В этом случае будет доступна настройка следующих параметров кэша:
Гарантированный объем (Reservation size)
Выбор программного модуля-обработчика (vFlash Cache Module)
Размер блока (настраивается в зависимости от гостевой ОС)
Что делать с кэшем при перемещении виртуальной машины посредством vMotion (перенести вместе с ней или удалить)
При vMotion сервер vCenter будет проверять наличие необходимых ресурсов кэширования для виртуальной машины на целевом хосте ESXi. Для совместимости с технологией VMware HA, виртуальная машина должна будет иметь доступные vFlash-ресурсы на хранилищах хостов в случае сбоя (соответственно, потребуется эти ресурсы гарантировать).
В целом vFlash в VMware vSphere обещает быть очень перспективной технологией, что особенно актуально на волне роста потребления SSD-накопителей, постепенно дешевеющих и входящих в повсеместное употребление.
В конце прошлой недели мы рассказали о документе, где приведено сравнение гипервизоров VMware vSphere, Microsoft Hyper-V и Red Hat Enterprise Virtualization (функциональность последнего там показана для бета-версии 3.1). На днях компания Red Hat объявила о выпуске окончательной версии платформы виртуализации Red Hat Enterprise Virtualization 3.1 для серверов и виртуальных ПК.
Напомним, что мы уже писали о возможностях версии 3.0, вышедшей в самом начале этого года, а вот что нового появилось в RHEV 3.1:
Поддержка до 160 виртуальных процессоров для ВМ
Поддержка до 2 ТБ оперативной памяти для ВМ
Поддержка последних линеек x86-процессоров
Live Snapshots - поддерживаются снапшоты работающих виртуальных машин
Улучшенный SPICE-клиент для работы с виртуальными ПК - нативная поддержка USB 2.0, в том числе для виртуальных машин Linux
Улучшения на дэшбоарде консоли управления в части статистической информации
Улучшения сетевого взаимодействия, включая горячее добавление/удаление виртуальных сетевых адаптеров (vNIC), поддержка bridge-less network (создание изолированных локальных сетей на хосте), зеркалирования портов (port mirroring), а также настройки MTU
Увеличенный объем поддерживаемых хранилищ, а также поддержка NFS v4
Технологическое превью механизма горячей миграции хранилищ ВМ Storage Live Migration
Улучшенный портал для пользователей с возможностью определения квот ресурсов для них (Technology Preview)
Новая политика виртуальных ПК "auto start"
Улучшения работы через WAN-соединения
Улучшенный Virtual Desktop Client
Интеграция с Red Hat Storage (содержащего GlusterFS тома)
Командный интерфейс с использованием REST API
Пакет разработки Python SDK с использованием REST API
Механизм Windows Driver Deployment для гостевых ОС
Правила фильтрации через механизм Default Network Filter (nwfilter) для виртуальных машин
В принципе, весьма немало. Скачать пробную версию решения Red Hat Enterprise Virtualization 3.1 можно по этой ссылке. Документ с полным описанием новых возможностей RHEV 3.1 доступен тут.
Привет. Меня зовут Александр Самойленко, и ровно 6 лет назад я начал писать на VM Guru о технологиях виртуализации и виртуальных машинах. В то время это был жиденький сайтик на крякнутой CMS-ке, с которой было временами очень сложно бороться. Тогда я работал в Veeam Software (это даже был еще не совсем Вим), про виртуальные машины в России еще знали мало, а тема виртуализации для многих была такой же далекой, как перспективы будущего в мини-сериале "Black Mirror" для современного человека. Но уже тогда в крупных российских энтерпрайзах инженеры крутили различные платформы виртуализации, лучшей из которых была VMware ESX Server (а многие, конечно же, помнят и Workstation начала двухтысячных - вау! компьютер в компьютере!).
Первый год на наш сайтик ходило 50-100 человек, писал я просто так для себя, а виртуальными машинами не занимался вовсе. Тогда же писал и статьи на iXBT (написал их аж где-то 20-30 штук, из которых мне самому понравилась тогда только вот эта). И да, в российском VMware тогда работал 1 (один) человек - старожилы помнят, кто это был.
Но потом интерес к виртуализации (тогда это было равно VMware для x86-платформ) стал сильно возрастать. Паша Новиков начал ездить на семинары, а мы тогда выпытывали у него, как нужно эстимировать проекты по виртуализации, хотя, конечно же, тогда еще он знал не больше нашего:). В VMware уже работало целых 3 человека (привет Юля и Виталик!). А мы с крякнутой CMS-ки переехали на самописный движок.
Ну а потом мы делали много чего - открыли компанию, сделали, наверное, самый большой на то время проект по виртуализации в России (нормальный был проект, ответственно подходили), женились, разводились, заводили детей. Так вот и прошли 6 лет или, если измерять по-другому - 2300 заметок. Все еще впереди.
Недавно компания HP выпустила первую версию продукта Virtualization Performance Viewer 1.0, предназначенного для обнаружения, диагностики и решения проблем в виртуальных средах. Virtualization Performance Viewer поставляется в бесплатном (ограниченная функциональность) и коммерческом изданиях.
HP Virtualization Performance Viewer поддерживает гипервизоры VMware vSphere и Microsoft Hyper-V, и доступен как виртуальный модуль (Virtual Appliance) на базе CentOS. Бесплатная версия также доступна как приложение для ОС Windows.
Основные возможности продукта:
Просмотр состояния и производительности виртуальной инфраструктуры, а также предоставление информации о ее компонентах в виде "Treemaps"
Утилиты для диагности и решения проблем с описанием возникших неполадок
Возможность предвидеть проблемы недостатка мощностей, а также идентифицировать недогруженные и перегруженные системы
Отличия бесплатного и коммерческого изданий:
Скачать HP Virtualization Performance Viewer можно по этой ссылке.
На днях компания Код Безопасности объявила о том, что сертификат ФСТЭК России на ПАК «Соболь» версии 3.0 был продлен до 07 декабря 2015 года. Сертификат подтверждает, что ПАК «Соболь версии 3.0 соответствует 2-му уровню контроля на отсутствие НДВ (в соответствии с требованиями РД Гостехкомиссии России) и может использоваться в автоматизированных системах до класса 1Б и в ИСПДн до класса К1 включительно.
ПАК «Соболь» версии 3.0 предназначен для реализации следующих защитных механизмов:
идентификация и аутентификация пользователей на входе в систему (непосредственно при запуске сервера);
ведение журнала безопасности;
сигнализация попыток нарушения защиты;
запрет загрузки с внешних носителей;
контроль конфигурации (PCI-устройств, ACPI, SMBIOS и оперативной памяти).
Более подробно о комплексе ПАК "Соболь" можно узнать по этой ссылке.
Как многие знают, ядром концепции компании Citrix является идеология предоставления доступа пользователя к своим данным и приложениям из любой точки и с любого устройства.
На днях эта концепция дала сбой - из-за багов приложение Citrix Receiver 5.6.3, выпущенное 28 ноября под iOS, было удалено из App Store.
Потенциально это событие может может повлиять на те компании, в которых CIO убедили пользователей и руководство, что с помощью Citrix XenDesktop/XenApp можно быстро получать доступ к данным своего ПК cо своих iPad и iPhone. Они рассказали о всех модных фишках продукта, включая MDX и ShareFile, а теперь это приложение нельзя никак получить уже несколько дней!
Интересно то, что это так называемый "distribution bug" - то есть ошибка, не касающаяся непосредственно функциональности приложения, а касается она возможностей доступа к данным, сохраненным предыдущей версией Citrix Receiver на iOS-устройстве. Соответственно, после преодоления бюрократической машины Apple, с выпуском исправленной версии Receiver, эта ошибка в скором времени будет исправлена. На момент написания заметки (0:20 мск, 3 декабря) по запросу "Citrix" в App Store приложение Receiver так и не находилось.
Таким образом, за последнее время слажали все три основных вендора в сфере виртуализации:
Продолжаем рассказывать о компании ИТ-ГРАД - первом облачном провайдере России, предоставляющем виртуальные машины VMware vSphere в аренду для организаций различного масштаба, являющейся также и системным интегратором. Специально под задачу создания виртуальной инфраструктуры ИТ-ГРАД разработала комплекты оборудования, сбалансированные по таким показателям как:
цена
производительность
надёжность
Предлагаемые системы позволяют полностью развернуть информационно-техническую инфраструктуру организации на 50-500 пользователей, включая следующие сервисы:
Доменная инфраструктура: MS Windows Server 2008R2 (DC, DNS, RADIUS, DHCP)
Электронная почта: MS Exchange Server 2010 (Relay, Exchange MBX, HT, CAS, TMG)
Объединенные коммуникации: MS Lync (Edge, FE, MS SQL)
Внутрикорпоративный портал MS SharePoint 2010
Инфраструктура открытых ключей (PKI) с возможностью обеспечения аутентификации 802.1x в проводной и беспроводной сети (Root CA0, Issuing CA1)
Комплексы укомплектованы всем необходимым для начала работы и не требуют дополнительного оборудования. Опциональные возможности позволяют легко наращивать производительность любого комплекса, либо изменять его качественные характеристики.
Для мониторинга инфраструктуры виртуализации VMware vSphere зачастую используется протокол SNMP (например, через серверы Open NMS , CACTI , PRTG и т.п.). До версии VMware vSphere 5.1 поддерживались только версии 1 и 2 протокола SNMP. С выпуском версии 5.1 была добавлена поддержка третьей версии этого протокола (SNMPv3), который имеет множество улучшений, в основном касающихся безопасности.
Также в процессе настройки SNMP на хостах ESXi можно выбрать способ приема агентом сообщений: от IPMI-сенсоров (как в прошлых версиях ESXi) или CIM-индикаторов. Кроме того, можно фильтровать отсылаемые на сервер мониторинга SNMP-сообщения.
Для настройки протокола SNMP версий 1 и 2 нужно сделать 4 простых шага:
1. Установить community string (по сути, это пароль) командой:
esxcli system snmp set –communities public
2. Установить сервер мониторинга (SNMP target), который включает адрес и порт, а также community string:
esxcli system snmp set –targets server.domain@161/public
3. Включить сервис SNMP на хосте ESXi:
esxcli system snmp set –enable true
4. Протестировать конфигурацию:
esxcli system snmp test
Для того, чтобы протестировать SNMP со стороны таргета можно использовать команду (для версии 2):
snmpwalk -v2c -c public esxserver.domain
Для настройки протокола SNMP версии 3 нужно сделать 8 шагов (не все обязательны):
1. Выставляем Engine ID для SNMP-агента (ID - это шестнадцатиричное значение от 5 до 32-х разрядов длиной):
esxcli system snmp set –engineid 766d77617265
2. Выставляем протокол аутентификации (SHA1, MD5 или none):
esxcli system snmp set –authentication SHA1
3. Устанавливаем протокол шифрования:
esxcli system snmp set –privacy AES128
4. Если мы включили протоколы шифрования в шагах выше, то нужно сгенерировать хэши для паролей аутентификации и шифрования (опция -r означает, что пароли вводятся прямо в команде):
esxcli system snmp hash -r -A pass1 -X pass2
5. Настраиваем пользователя SNMP, указывая хэши, полученные в предыдущей команде (user - ваш пользователь):
esxcli system snmp set –users user/f9f7311379046ebcb5d134439ee5b7754da8a90f/d300f16eec59fb3b7ada7844ff764cbf4641fe5f/priv
6. Устанавливаем SNMP-таргет:
esxcli system snmp set –v3targets server.domain@161/user/priv/trap
7. Включаем SNMP:
esxcli system snmp set –enable true
8. Тестируем настройки:
esxcli system snmp test
Точно так же, как и для версий 1 и 2, со стороны сервера можно проверить работоспособность настроек SNMP, указав введенные ранее пароли:
snmpwalk -v3 -u user -l AuthPriv -a SHA -A pass1 -x AES -X pass2 esxserver.domain
Все вышеперечисленное можно сделать и через vSphere CLI (нужно ставить на отдельную машину) в интерактивном режиме с помощью скрипта vicfg-snmp.pl:
Если вам не хочется заморачиваться с установкой vSphere CLI, то можно использовать скрипт configureSNMPv3.sh, с помощью которого настройка происходит легко и просто:
Недавно компания VMware разослала своим клиентам и партнерам письмо, в котором сообщалось об окончании поддержки линейки VMware vSphere 4.x, построенной, в том числе, на базе "толстого" гипервизора VMware ESX. Теперь эта новость доступна на официальном сайте VMware.
Дата окончания продаж vSphere 4.x: 15 августа 2013 г.
В связи с этим пользователям до 15 августа следующего года рекомендуется создать или сохранить резервную копию соответствующих дистрибутивов и сформировать необходимые лицензионные ключи на портале My VMware для поддержки или расширения сред на базе гипервизора vSphere ESX версии 4.x или vMA версий 1 и 4. Эти операции необходимо выполнить до 15 августа 2013 г. Компания VMware не будет предоставлять никакие двоичные файлы (дистрибутивы, утилиты и т.п.) и лицензионные ключи для гипервизора vSphere ESX 4.x и для vMA версий 1 и 4 после 15 августа 2013 г.
Касательно поддержки (SnS) и жизни после 15 августа:
Жизненный цикл поддержки гипервизора vSphere ESX 4.X и vMA.
Датой окончания поддержки остается 21 мая 2014 г. Подробнее о жизненном цикле поддержки VMware.
Возможность использования заказчиками гипервизора vSphere ESX 4.x или vMA версий 1 и 4 после 15 августа 2013 г.
Заказчики сохраняют возможность использования лицензированных копий продукта после даты окончания продаж и даты окончания поддержки. Тем не менее они не смогут загружать дистрибутивы и формировать новые лицензионные ключи после даты окончания продаж и получать техническую поддержку и подписку после даты окончания поддержки.
Продажа и поддержка vSphere ESXi 4.X — БЕЗ изменений.
Продажа vMA 4.1, 5 и 5.1 и поддержка всех версий — БЕЗ изменений.
На днях сообщество разработчиков Xen объявило о выпуске обновленной версии платформы Xen Cloud Platform 1.6 (XCP), которая предназначена для управления облачной инфраструктурой на базе гипервизора Xen (в каком-то смысле это аналог коммерческого XenServer). Напомним, что о решении Xen Cloud Platform версии 1.1 мы уже писали годом ранее, а в стадии беты версия 1.6 уже находилась с октября этого года.
XCP построена на базе свободного гипервизора Xen (в новой версии - 4.1.3), к которому прилагаются различные возможности для построения облачных инфраструктур посредством Xen API toolstack. Платформа XCP распространяется под лицензией GNU General Public License (GPL2).
Технология Storage XenMotion, позволяющая проводить миграцию работающих виртуальных машин на другой хост и хранилище, при этом хосты могут быть в разных пулах и не иметь общего хранилища, т.е. горячая миграция ВМ доступна между локальными дисками хост-серверов.
Технология Live Virtual Disk Image migration, предоставляющая возможности миграции ВМ без ее выключения.
Улучшения сетевого взаимодействия:
Поддержка Link Aggregation Control Protocol (LACP)
Ubuntu 10.04, Debian Squeeze, Oracle EL 6.0, SLES 10 SP4
Ubuntu 12.04, RHEL/CentOS 6.2, Oracle EL 6.1 & 6.2, Windows 8
В целом с версии 1.1 платформа XCP 1.6 получила немало новых функций (релизная версия 1.5 так и не была выпущена), поэтому некоторые сервис-провайдеры и крупные организации могут уже начать задумываться о построении инфраструктуры на базе этого решения. Более подробно о новой версии Xen Cloud Platform 1.6 рассказано тут, а по этой ссылке ее можно скачать.
TechEd Russia – главная технологическая конференция Microsoft, посвященная реализации бизнес-задач с помощью современных технологий. Будут освещены как ключевые бизнес сценарии и технологии для их реализации, так и подробные технические доклады по всему спектру ключевых продуктов и технологий Microsoft. Таги:
Не так давно мы писали о планируемом VMware продукте VMware vCenter Multi-Hypervisor Manager (MHM), который позволяет управлять серверами и виртуальными машинами на платформе Hyper-V. На днях компания VMware выпустила первую версию плагина Multi-Hypervisor Manager, который, конечно же, не поддерживает Hyper-V 3.0 в Windows Server 2012 (конечно же - потому что VMware в последнее время взяла моду выпускать продукты без поддержки последних версий). Однако, вроде бы, в скором времени обещают версию и под новый Hyper-V.
VMware vCenter Multi-Hypervisor Manager поставляется в виде плагина к "толстому" клиенту vSphere Client (Web Client не поддерживается), который предоставляет доступ к дереву объектов Microsoft Hyper-V на базе следующих ОС:
Microsoft Hyper-V Server 2008
Microsoft Hyper-V Server 2008 R2
Напомним, что, согласно архитектуре решения, MHM имеет не только клиентскую часть, но и серверный компонент:
Для установки серверной части потребуются следующие вычислительные ресурсы:
2 CPU на частоте 2 ГГц или более
4 ГБ памяти
1 ГБ дискового пространства
Сетевой адаптер
Между всеми компонентами данной архитектуры осуществляется безопасная коммуникация по HTTPS.
Надо отметить, что серверная часть Multi-Hypervisor Manager - это Windows-приложение, поэтому если вы используете, например, виртуальный модуль VMware vCenter Server Appliance (vCSA), то придется устанавливать MHM на отдельную виртуальную или физическую Windows-машину и связывать его с сервисом vCenter. И да, надо отметить, что:
vCenter Multi-Hypervisor Manager is a fully-supported vCenter Server feature. VMware provides support for all vCenter Multi-Hypervisor Manager or vSphere related issues
Возможности vCenter Multi-Hypervisor Manager 1.0 для хостов Hyper-V:
Добавление/удаление хостов Hyper-V в окружение vCenter
Информация о конфигурации хостов Hyper-V (processor, memory, network)
Создание/удаление виртуальных машин на Hyper-V
Удаленная консоль как к самим хостам Hyper-V, так и к виртуальным машинам
Простейшие операции по управлению питанием хостов и виртуальных машин (power off, power on, suspend, shut down guest и reset)
Изменение настроек виртуальных машин: память, vCPU, диски, сетевые адаптеры и прочее виртуальное "железо"
Отображение задач для хостов Hyper-V и виртуальных машин на общей панели задач и событий vSphere Client
Интегрированная авторизация с vCenter, а также поддержка механизма пользователей и ролей
Скачать VMware vCenter Multi-Hypervisor Manager 1.0 можно по этой ссылке. Есть еще FAQ в KB 2037570.
Для осуществления делегирования административных задач пулы виртуальных десктопов отдельных клиентов, которым предоставляется услуга (возможно филиалов, других предприятий и т.п.) следует располагать в своей выделенной папке (folder) иерархии VMware View Manager. Пулы виртуальных десктопов различных типов также рекомендуется располагать в отдельных папках (folder) иерархии VMware View Manager... Таги: VMware, View, Security, Blogs, Enterprise, vSphere, VDI
Многие знают компанию StarWind как производителя средства номер 1 для создания отказоустойчивых хранилищ StarWind iSCSI SAN под виртуальные машины VMware vSphere. Не так давно вышла обновленная версия StarWind iSCSI SAN 6.0 этого решения. Но, как известно, StarWind предлагает еще и отказоустойчивое решение для серверов Hyper-V.
15 ноября компания StarWind сделала 3 важных анонса, которые вам будут, безусловно, интересны:
Во-первых, вышла новая версия продукта под гипервизор Microsoft Hyper-V: StarWind Native SAN 6.0 (документ с описанием новых возможностей вот тут)
Во-вторых, вышла финальная версия решения для резервного копирования виртуальных машин на VMware vSphere, поставляемого в виде плагина - VMware Backup Plug-in. Теперь продукт полностью поддерживает новую платформу VMware vSphere 5.1.
Поскольку из этих новостей самая интересная - третья, то мы расскажем о бесплатном продукте StarWind Native SAN for Hyper-V Free edition. Он позволяет построить небольшой, но отказоустойчивый кластер хранилищ из двух серверов Microsoft Hyper-V на основе протокола iSCSI, без необходимости вложений во что бы то ни было - серверы под СХД или лицензии. Можно взять 2 обычных хост-сервера Hyper-V и забацать кластер.
Давайте взглянем на отличие бесплатного продукта от его платной версии:
StarWind Native SAN for Hyper-V
Free Edition - бесплатно
Small Business
Midsize Business
Enterprises
Компоненты продукта
Лицензируемая емкость хранилищ
Не ограничена
(HA-хранилище ограничено размером 128 ГБ)
1 ТБ / 2 ТБ (HA)
4 ТБ / 8 ТБ (HA)
16 ТБ/Не ограничено (HA)
Централизованное управление
StarWind Console
StarWind Console
StarWind Console
StarWind Console
Число серверов, входящее в лицензию
2
2 или 3
2 или 3
2 или 3
Число одновременных соединений по iSCSI к хранилищам
Из таблицы видно, что бесплатная версия StarWind Native SAN for Hyper-V Free edition практически ничем не отличается от платной, кроме ограничения на размер отказоустойчивого хранилища в 128 ГБ. Полное сравнение платного и бесплатного изданий StarWind Native SAN for Hyper-V доступно по этой ссылке.
Мы уже не раз затрагивали тему vswp-файлов виртуальных машин (файлы подкачки), которые используются для организации swap-пространства гипервизором VMware ESXi. Эти файлы выполняют роль последнего эшелона среди техник оптимизации памяти в условиях недостатка ресурсов на хосте. Напомним, что в гипервизоре VMware ESXi есть такие техники как Transparent Page Sharing, Memory Ballooning, a также Memory Compression, которые позволяют разбираться с ситуациями нехватки памяти, необходимой виртуальным машинам.
Напомним также, что первым эшелоном оптимизации памяти является техника Memory Ballooning. Она работает за счет использования драйвера vmmemctl.sys (для Windows), поставляемого вместе с VMware Tools. Он позволяет "надуть" шар внутри гостевой ОС (balloon), который захватывает физическую память, выделенную этой ОС (если ее много), и отдает ее другим гостевым операционным системам, которые в ней нуждаются. Этот balloon не позволяет гостевой ОС производить работу приложений с данной областью памяти, поэтому если им потребуется дополнительная память - она будет уходить в гостевой своп. Это более правильный подход, чем свопировать гостевую ОС в файл подкачки vswp на томе VMFS, поскольку операционная система сама лучше разбирается, что и когда ей класть и доставать из свопа (соответственно, быстродействие выше).
Однако, когда памяти у всех виртуальных машин совсем мало или отдельной ВМ ее требуется больше, чем сконфигурировано, а также происходит постоянное обращение к памяти (особенно, если в гостевых ОС нет VMware Tools), гипервизор начинает использовать vswp-файл подкачки, который по умолчанию находится в папке с виртуальной машиной. Мы уже писали о том, что в целях повышения быстродействия можно положить vswp-файлы виртуальных машин на локальные SSD-хранилища серверов ESXi, а также о том, как удалять мусорные файлы vswp.
Ниже мы приведем 8 фактов о swap-файлах виртуальных машин, которые основаны на вот этой заметке Фрэнка Деннемана:
1. Хранение vswp-файлов на локальных дисках сервера ESXi (в том числе Swap to Host Cache) увеличивает время vMotion. Это очевидно, так как приходится копировать vswp-файл в директорию ВМ (или другую настроенную директорию), чтобы его видел целевой хост.
2. С точки зрения безопасности: vswp-файл не чистится перед созданием. То есть там лежат не нули, а предыдущие данные блоков. Напоминаем, что размер файла подкачки равен размеру сконфигурированной памяти ВМ (если не настроен Reservation). Если же у машины есть Reservation, то размер vswp-файла определяется по формуле:
То есть, если в настройках памяти машины ей выделено 4 ГБ, а Reservation настроен в 1 ГБ, то vswp-файл будет составлять 3 ГБ.
3. Как происходит копирование vswp-файла при vMotion? Сначала создается новый vswp-файл на целевом хосте, а потом копируются только swapped out страницы с исходного в целевой vswp-файл.
4. Что происходит при разнице в конфигурации размещения vswp-файлов в кластере и для отдельных хостов? Напомним, что в настройках кластера VMware vSphere есть 2 опции хранения vswp-файлов: в папке с ВМ (по умолчанию) и в директории, которая указана в настройках хоста:
Если на одном хосте настроена отдельная директория для vswp, а на другом нет (то есть используется папка ВМ), то при vMotion такой виртуальной машины vswp-файл будет скопирован (в папку с ВМ), несмотря на то, что целевой хост видит эту директорию на исходном.
5. Обработка файлов подкачки при нехватке места. Если в указанной директории не хватает места для свопа ВМ, то VMkernel пытается создать vswp-файл в папке с ВМ. Если и это не удается, то виртуальная машина не включается с сообщением об ошибке.
6. vswp-файл лучше не помещать на реплицируемое хранилище. Это связано с тем, что используемые страницы памяти, находящиеся в двух синхронизируемых файлах, будут постоянно реплицироваться, что может вызывать снижение производительности репликации, особенно если она синхронная и особенно при vMotion в недефолтной конфигурации (когда происходит активное копирование страниц и их репликация):
7. Если вы используете снапшоты на уровне хранилищ (Datastore или LUN), то лучше хранить vswp-файлы отдельно от этих хранилищ - так как в эти снапшоты попадает много ненужного, содержащегося в своп-файлах.
8. Нужно ли класть vswp-файлы на хранилища, которые развернуты на базе thin provisioned datastore (на уровне LUN)? Ответ на этот вопрос зависит от того, как вы мониторите свободное место на тонких лунах и устройствах своего дискового массива. При создании vswp-файла VMkernel определяет его размер и возможность его создания на уровне хоста ESXi, а не на уровне устройства дискового массива. Поэтому если vswp-файл активно начнет использоваться, а вы этого не заметите при неправильной конфигурации и отсутствии мониторинга тонких томов - то могут возникнуть проблемы с их переполнением, что приведет к сбоям в работе ВМ.
В начале ноября на совете директоров компании ИТ-ГРАД, было принято решение о предоставлении облачных сервисов по новой модели DedicatedSaaS.
Все специалисты IT-сферы знают, что рынок облачных услуг начал активно развиваться вместе с появлением высокоскоростного интернета, который позволил сделать работу более производительной и удобной. Тогда же и появились первые модели по которым предоставляются облачные услуги: IaaS и SaaS. Компания ИТ-ГРАД стала одной из первых предоставлять услуги по модели SaaS, но накопленный опыт показал, что и у этой модели есть свои недостатки, поэтому руководством компании было принято решение о переходе на новый уровень предоставления «Dedicated SaaS».
Что означает этот термин, и почему такой подход является основой всех SaaS решений компании ИТ-ГРАД?
«DedicatedSaaS» – это принципиально новая для России концепция в области предоставления программного обеспечения как сервиса.
«Сталкиваясь с нежеланием того или иного клиента использовать SaaS, я подробно выяснял, что является препятствием для перехода в облако. Ряд возражений, таких как зависимость от интернет канала и относительно низкая скорость работы, удавалось преодолеть. А с течением времени эти вопросы решаются всё проще – расширяются каналы связи, технические недостатки уходят в прошлое. Причиной отказа от SaaS, как правило, были другие проблемы»
Вадим Сезенин
менеджер по продажам ИТ-ГРАД
Как показал опыт компании ИТ-ГРАД традиционная модель SaaS имеет ряд недостатков. Среди них основными являются:
Низкая кастомизируемость. SaaS-решения безнадежно отстают в части тонкой настройки под клиента от традиционных инсталлируемых у заказчика приложений.
Сложность интеграции SaaS приложения с остальной инфраструктурой компании. Это в значительной степени повышает затраты на ИТ, полностью поглощая экономию от использования ПО как сервис.
Угроза непрерывности бизнеса. В случае катастрофы, затрагивающей дата-центр SaaS-провайдера велика вероятность безвозвратной потери всех данных.
Невысокая функциональная масштабируемость. По мере роста компании в значительной степени усложняются бизнес-процессы. На сегодняшний день только единичные SaaS-решения одинаково хорошо удовлетворяют все потребности как малого бизнеса, так крупных клиентов. В большинстве же случаев организации приходится по мере роста менять SaaS провайдера вместе с платформой на решение более высокого уровня.
Все перечисленные проблемы вызваны таким элементом архитектуры SaaS услуги как Multitenancy (многоорганизационность или множественная аренда). Подобная архитектура предполагает использование одной инсталляции приложения для большого количества организаций-заказчиков. Другим подходящим термином для такой модели является «Shared SaaS».
Противоположностью SharedSaaS является DedicatedSaaS (отдельная инсталляция под каждого заказчика).
Одно и то же приложение может архитектурно предоставляться как в Shared, так и в Dedicated режиме. Почему же SaaS стараются прочно ассоциировать с многоорганизационной моделью?
Shared SaaS даёт значительные преимущества для провайдера. Позволяет экономить на вычислительных ресурсах, оперативной памяти и дисковом пространстве, потребляемых экземпляром приложения. По сравнению с большим количеством инсталляций такая экономия существенна. Уменьшаются затраты на лицензирование операционной системы и СУБД. Упрощается процедура обновления на новые версии и развертывания промежуточных релизов.
Поэтому подавляющее большинство SaaS провайдеров активно продвигает идею о том, что Multitenancy или многоорганизационность – это необходимый компонент модели предоставления программного обеспечения как услуги. Но так ли это, и есть ли положительные моменты для клиента от соседства с другими компаниями на одном экземпляре информационной системы?
Такие положительные аргументы в пользу SaaS как высокая скорость развертывания, отсутствие необходимости в установке клиентов на рабочие станции (и как следствие – мультиплатформенность), сокращение затрат на услугу и предсказуемость платежей – не являются спецификой или следствием организации услуги в Shared режиме, о чем мы расскажем ниже. А вот с точки зрения недостатков SharedSaaSявляется причиной всех упомянутых в начале проблем, а также добавляет к ним следующие:
Угрозы информационной безопасности и конфиденциальности данных. Так как пользователи Shared приложения работают с общим экземпляром системы, изоляция данных осуществляется только на уровне самого приложения. Это означает, что ошибки в системе разграничения прав доступа могут привести к угрозе утечки информации пользователям других организаций.
Неуправляемость процедур обновления версий системы. Очередные версии приложения развертываются одновременно для всех заказчиков. Это может означать как значительные задержки с накатом новых версий, связанные с длительным тестированием обновления общей для всех системы, так и относительно преждевременное для конкретного заказчика обновление на новую версию.
Теперь мы видим, какие недостатки имеет архитектура SharedSaaS. Уходят ли они при переходе на модель DedicatedSaaS? В модели Dedicated SaaS полностью устранены все характерные недостатки современных SaaS-решений:
Клиент может дорабатывать и донастраивать совместно с провайдером приложение под собственные нужды (при контроле совместимости доработок с новыми версиями), используя для этого все возможности, заложенные в платформу информационной системы.
Выделенная инсталляция позволяет сравнительно легко интегрировать приложение с другими системами, которые также размещаются в арендуемом облаке.
Наличие собственных экземпляров приложения и баз данных позволяет без значительных усилий настроить резервное копирование, как на удаленную резервную площадку, так и на собственную площадку заказчика.
Значительно упрощается переход на новую платформу, связанный с ростом бизнеса.
Наличие выделенного под каждую инсталляцию сервера (или комплекса серверов) гарантирует максимальную изоляцию данных клиента от других заказчиков в рамках одного SaaS провайдера. Это обеспечивает высокий уровень информационной безопасности.
Приложение обновляется тогда, когда в этом есть потребность бизнеса клиента.
Поскольку речь идет о выделенных под каждую инсталляцию серверах, следует ли из этого, что использование модели Dedicated SaaS означает более высокие издержки для провайдера и более высокие цены для клиентов?
Снижение стоимости решения в модели Shared SaaS обеспечивается за счет многоорганизационности, но существуют и другие, зачастую более эффективные, способы снижения затрат провайдера без использования Multitenancy. Лучшие показатели уменьшения издержек на обслуживание большого количества пользователей показывают системы виртуализации серверных ресурсов. Технологическим лидером в этом направлении является компания VMware.
Внедрение технологий VMware позволяет не только использовать серверные мощности более эффективно, чем в режиме Multitenancy, но и обеспечить автоматическое развертывание комплексов серверов с преднастроенными приложениями. Дополнительно снизить затраты провайдеру Dedicated SaaS позволяет использование автоматизированных средств развертывания обновлений на большое количество серверов клиентов. В конечном счете, издержки Dedicated SaaS при правильной организации архитектуры услуги не превышают аналогичных издержек для Shared SaaS, при этом сохраняются все преимущества: и быстрота внедрения, и высокая скорость развертывания, и относительно низкая стоимость решения с ежемесячной платой за реальное потребление.
Компетенция, накопленная нами в области виртуализации, построения облаков и организации процессов оказания ИТ-услуг, позволяет нам на сегодняшний день заявить о том, что реализованный нами подход к предоставлению ПО в модели DedicatedSaaS – это эффективный инструмент повышения конкурентоспособности наших клиентов».
Оказывается, еще в сентябре компания VMware обратила внимание пользователей на один интересный продукт - VMware vCenter Support Assistant. Он призван помочь пользователям в сборе и отправке диагностических данных о своей виртуальной инфраструктуре, а также обращении в техническую поддержку.
Продукт будет представлять собой виртуальный модуль (Virtual Appliance) для VMware vCenter и позволит грамотно оформлять Support Request'ы, а также взаимодействовать с инженерами техподдержки VMware в удобном интерфейсе. Сейчас он находится в стадии бета-тестирования.
vCenter Support Assistant позволит оформлять запросы в техподдержку не только для VMware vSphere, но для любого другого продукта VMware, для которого куплена поддержка на базе SnS или по инцидентам. На данный момент поддерживаются версии VMware vSphere 5.1, 5.0 и 4.1.
После установки, VMware vCenter Support Assistant появится как плагин к vSphere Client:
Дальше логинимся:
и создаем Support Request:
После детального описания проблемы (суть, критичность, категория, статьи KB) можно собрать и прикрепить диагностическую информацию:
После того, как запрос в техподдержку будет сформирован, а необходимые логи и конфиги загружены, можно посмотреть статус своего обращения:
В целом, должна быть удобная штука, особенно для больших компаний, где много администраторов, виртуальных машин и, соответственно, проблем. Для записи в бета-тестеры продукта VMware vCenter Support Assistant нужно использовать эту ссылку.
RSS
\
(128 ГБ)
